寫在前面：
這個系列主要想記錄我自己研究及參與 EU Cyber Resilience Act（CRA）導入過程中的一些心得、觀察與個人解讀，也希望藉這 30 天和同樣關注 CRA、Product Security 的朋友交流。
CRA 畢竟是歐盟法規，因此文章內容僅代表我現階段的理解與看法，不代表主管機關或法規的正式解釋，也不代表文中提到的做法一定能被歐盟接受。相關要求仍應以 CRA 正式法規、European Commission 後續 Guidance、Harmonised Standards 及主管機關實務為準。今天比較偏向 Project Management 與 Implementation Planning，也不是 CRA 規定企業一定要按照這個時程執行。
每家公司 Product Portfolio、開發模式、EU Market Strategy 與既有 Product Security 成熟度都不同，因此以下 Roadmap 比較像是我自己參與 CRA 導入後，逐漸形成的一套專案規劃思路，實際仍應依企業情境與最新法規、Guidance 及 Standards 發展調整。

Day 20 把人找出來之後，下一個問題就是：什麼時候要做完？
上一篇談到 CRA Organization 與 RACI。
做到這裡，我自己慢慢把 CRA 從一個「Security Project」，重新理解成一個跨部門的 Product Compliance Program。
但組織拉起來、Workstream 拆出來之後，馬上就會碰到下一個很現實的問題：
這麼多事情，到底什麼時候要完成？
第一次看到 CRA 的主要義務從 2027 年 12 月 11 日開始適用，我其實也會直覺覺得：「現在才 2026 年，好像還有一年多。」
但真正把工作拆開之後，我的感覺反而是：
一年多，其實沒有想像中那麼長。
因為 CRA 並不是到 2027/12/10 寫完幾份文件，隔天公司就突然 Compliance。
它牽涉 Product Development、Vulnerability Handling、SBOM、Supplier Management、Technical Documentation、Conformity Assessment、CE，以及很多跨部門流程。
更重要的是，CRA 還有一個日期比 2027/12/11 更早。

一、第一個我會圈起來的日期：2026/9/11
CRA Article 71 規定，Article 14 的部分 Reporting Obligations 從：
2026 年 9 月 11 日
開始適用。
也就是 Actively Exploited Vulnerability，以及 Severe Incident Having an Impact on the Security of the Product 等相關 Reporting Requirement，並不是等到 2027 年底才開始。
這件事情對我安排 Roadmap 的影響很大。
因為如果站在現在這個時間點來看，Article 14 已經不是一個「未來再準備」的 Compliance Item，而是近期就必須具備的 Operational Capability。
所以如果讓我安排 CRA 專案，我第一個 Priority 不會是把所有產品的 Technical Documentation 全部寫完，而會先問：
Article 14 Ready 了嗎？

二、什麼叫 Article 14 Ready？
我自己不會只看公司有沒有一份 Reporting SOP。
真正要確認的是：Vulnerability 從哪裡進來？誰負責 Triage？誰確認是否存在 Active Exploitation？誰判斷是否涉及 CRA Reporting？24 小時、72 小時以及後續 Reporting 的流程怎麼跑？ENISA Single Reporting Platform 的帳號、權限與操作人員準備好了嗎？
再往實務一點想，還會遇到很多平常 SOP 不一定寫得出來的問題。
例如星期五晚上收到 Vulnerability Report 怎麼辦？海外團隊發現問題，要透過什麼管道通知？Product Impact Analysis 需要 R&D，但 R&D 在另一個時區怎麼辦？誰有權啟動對外 Reporting？相關 Decision Record 與 Evidence 又要放在哪裡？
如果這些問題還沒有答案，我自己不太會認為：
Article 14 已經真的 Ready。
所以 2026 年這個階段，我會先把 PSIRT、Reporting、Escalation、Contact List、Reporting Authority、Evidence Retention 與 Tabletop Exercise 串起來，讓整個流程至少真的跑過一次。
這也讓我覺得，CRA Roadmap 不能單純按照法條章節順序做，而應該按照：
Regulatory Deadline + Implementation Lead Time + Risk
來排優先順序。

三、第二條線，我會盡早開始 Product Inventory
Article 14 是眼前最急的，但另一件不能拖太久的事情是：
Product Inventory。
原因很簡單。如果連有哪些 Product 可能適用 CRA 都不知道，後面的 Classification、Risk Assessment、SBOM、Technical Documentation、Conformity Assessment，自然也不知道工作量到底有多大。
所以我會先建立一份 CRA Product Master List，至少逐步掌握 Product Family、Part Number、Product Owner、EU Market Status、Software / Firmware、Connectivity、Support Status、CRA Applicability 與 Classification。
我自己會把 Product Inventory 看成：
整個 CRA Program 的 Master Scope List。
而且這張表不只是 Compliance List。後面 Risk Assessment、SBOM、Technical Documentation、Article 14 Product Impact Analysis，甚至專案進度追蹤，都可能回到同一份 Product Scope。

四、產品很多時，我不會一開始就追求每一顆都分析到最細
這對 Semiconductor Company 我覺得特別實際。
如果公司有幾千個甚至更多 Part Number，一開始就要求每一個 Part Number 完成完整 CRA Analysis，專案很可能很快就卡住。
所以我自己比較傾向先做 Product Family Level Screening。
第一輪先分成：
Clearly In Scope / Clearly Out of Scope / Need Further Assessment
第二輪再針對 In Scope 或不明確的 Product Family，進一步做 Applicability 與 Classification。
必要時，再往 Part Number 層級展開。
這樣做的目的不是降低 Requirement，而是先把有限的時間與人力放在真正需要分析的產品上。

五、Scope 大致出來後，我才會開始做 Gap Assessment
知道有哪些產品之後，下一個問題自然就是：
我們現在到底離 CRA 多遠？
這時我會開始盤點既有能力。例如 SSDLC 有沒有？Threat Modeling 有沒有？Security Requirement 有沒有？SAST / SCA 做到什麼程度？SBOM 能不能產？有沒有 Vulnerability Monitoring？PSIRT 能不能處理 Product Vulnerability？Supplier Security、Security Update、Support Period、Technical Documentation 又做到哪裡？
但我覺得這裡有一個很重要的觀念：
不要一看到 CRA，就認為所有制度都要重新做。
很多公司其實已經做了不少事情，只是以前不叫 CRA。

六、我會先做 Existing Process Mapping，而不是一直新增「CRA 文件」
例如公司本來就有 Secure Coding Standard，我不一定會再建立一份《CRA Secure Coding Standard》。
原本已經有 Vulnerability Management，就先看能不能補上 Product Context 與 CRA Reporting Requirement；原本有 Product Change Management，就看看能不能加入 Day 17 談的 Substantial Modification Assessment；原本有 Supplier Management，也可以評估怎麼加入 Product Security Due Diligence。
所以我自己會先做：
CRA Requirement → Existing Process Mapping
然後再決定每一項到底是：
Modify / Extend / Create New
這跟 Day 20 談 Organization 的想法其實是一樣的。
我不太希望 CRA 最後變成公司旁邊又長出一套完全獨立的制度，而是希望它逐漸進入原本 Product Development、Supplier、PSIRT、Quality 與 Product Compliance Process。

七、真正需要比較長時間的，是把 CRA 放進 Product Development Lifecycle
寫一份 Procedure，可能幾週就可以完成。
但要讓 R&D 真正改變 Product Development 的工作方式，我覺得通常不會這麼快。
例如 Product Planning 階段加入 CRA Applicability；Architecture 階段加入 Threat Modeling；Design 階段加入 Security Requirement；Implementation 加入 Secure Coding、SAST、SCA；Verification 加入適當的 Security Testing；Release 時產出 SBOM 與相關 Security Evidence；Maintenance 階段持續 Vulnerability Monitoring 與 Security Update。
這些事情如果真的要變成 Engineering Process，通常還需要 Tool、Template、Training、Pilot，以及幾輪 Process Adjustment。
所以：
SSDLC 是我不太會拖到 2027 下半年才開始的項目。
因為它不是補一份文件，而是在改 Product Development Lifecycle。

八、SBOM 我也會早一點做 Pilot
SBOM 看起來好像只是產出一份 Component List，但真正開始做，很快可能就會發現事情沒有那麼單純。
不同 Product Team 可能使用不同 Build System；Firmware Architecture 不一樣；Open Source Component Identification 不完整；Third-party Binary 看不到 Dependency；Component Version Naming 也可能沒有一致規則。
所以我自己不太會一開始就要求所有 Product 全面導入。
我比較可能選幾個代表性的 Product 做 Pilot，例如一個 Software Component 比較少的、一個 Firmware 比較複雜的，再加上一個 Third-party Component 很多的 Product。
先從 Pilot 找出：
我們真正的問題到底在哪裡。
再逐步 Scale。

九、Supplier Security 也不能太晚，因為外部 Lead Time 通常比內部長
內部 Procedure 今天決定要改，也許幾週後就可以開始執行。
但 Supplier 不一定。
如果 CRA 導入後需要增加 Vulnerability Notification、Security Update、SBOM、Support Period 或其他 Product Security Requirement，可能牽涉 Procurement、Legal、R&D 與 Supplier 之間多輪討論。
尤其既有 Long-term Supplier 的 Contract 可能早就簽了很多年，要重新調整不一定那麼快。
所以我自己會把：
Supplier Requirement
視為 CRA Roadmap 裡很容易低估 Lead Time 的項目。
這種工作如果拖到 2027 年最後幾個月才開始，我會覺得風險滿高。

十、Technical Documentation，我反而希望它是「邊做邊長」
Day 14 談過 Technical Documentation。
如果等到 2027 年下半年才突然通知所有 Product Team：
「請把過去兩年的 CRA Evidence 全部交出來。」
我猜場面可能會滿精彩。
Test Result 找不到、Product Version 對不起來、SBOM 已經更新過好幾版、Risk Assessment 不知道對應哪個 Release，這些事情其實都很容易發生。
所以我自己比較希望從 Pilot Product 就開始建立 Technical Documentation Structure，然後隨著 Product Development 逐步累積 Evidence。
換句話說：
Technical Documentation 不應該只是 Release 前才開始寫的文件，而比較像 Product Lifecycle 中逐步累積的 Evidence Package。
這也跟前幾天一直談的 Evidence Chain 接得起來。

十一、到了 2027 年，重點應該逐漸從「制度建立」轉向「Product Implementation」
如果 2026 年比較偏向 Foundation，我自己會希望 2027 上半年開始大量進入 Product-level Implementation。
也就是針對 In-scope Product / Product Family，逐步完成 Cybersecurity Risk Assessment、Annex I Mapping、Security Verification、SBOM、Support Period、Vulnerability Handling 與 Technical Documentation。
這時 CRA 就不能再只停留在 Corporate-level Policy。
因為最後真正需要建立 Conformity Basis 的：
還是 Product。
所以我自己會把 2026 與 2027 的重心稍微分開：
2026：Build the Capability
2027：Apply the Capability to Products
當然實際上兩者一定會重疊，不會真的切得這麼乾淨，但這樣對我來說比較容易管理。

十二、Conformity Assessment Strategy 也不能最後才決定
Day 15 談過，不同 Product Classification 可能走不同的 Conformity Assessment Route。
如果是 Default Category，可能可以採 Module A Internal Control；但如果是 Important Class II 或其他需要 Third-party Conformity Assessment 的情境，就要開始考慮 NB Availability、Assessment Lead Time、Evidence Expectation 與 Cost。
所以當 Product Classification 比較穩定之後，我會盡早把：
Conformity Assessment Strategy
拉出來討論。
而不是等 Product 全部做完，到了 2027 年才突然問：
「這個是不是要找 NB？」
尤其 NB Ecosystem 本身也還在逐步建立，越晚開始了解，Project Schedule 的不確定性可能越高。

十三、Harmonised Standards 還在發展，要不要乾脆等？
這是現在做 CRA 很容易碰到的問題。
如果 Harmonised Standards 還沒有全部 Ready，那是不是等 Standards 都確定之後再開始，反而比較不會做錯？
我自己目前不太傾向這樣做。
因為很多基礎能力，其實不需要等 Harmonised Standards 才開始。
Product Inventory、PSIRT、Vulnerability Handling、SBOM Capability、Secure Development、Supplier Management、Evidence Management，這些即使未來 Standard 的細節持續調整，大方向仍然需要。
所以我自己比較傾向：
先建立 Capability，再持續 Mapping Standards。
而不是：
等所有 Standards 都完整之後，才開始建立 Capability。
這樣即使後續要求有調整，我們比較像是在既有 Framework 上調整，而不是從零開始。

十四、如果讓我自己排一張簡化 Roadmap
我目前大概會先分成四個階段：
階段 我會優先處理的事情
Phase 1：Immediate Readiness Article 14、PSIRT、Reporting、Product Scope
Phase 2：Foundation Classification、Gap Assessment、SSDLC、SBOM Pilot、Supplier Requirement
Phase 3：Product Implementation Risk Assessment、Annex I Mapping、Testing、Technical Documentation
Phase 4：Conformity & Operationalization Conformity Assessment、DoC、CE、Monitoring、Audit / Exercise
這當然不是 CRA 官方 Roadmap。
只是我自己在面對很多平行 Workstreams 時，比較容易管理的一種方式。

十五、如果真的放進 2026～2027，我會這樣安排重心
2026 下半年，我會優先關注 Article 14 Readiness、CRA Governance、Product Inventory、Initial Classification、Gap Assessment、SSDLC Framework、SBOM Pilot，以及 Supplier Requirement Design。
到了 2027 上半年，重心開始往 Product-level Risk Assessment、Threat Modeling、Annex I Mapping、SBOM Deployment、Security Testing 與 Technical Documentation 移動。
2027 下半年，則逐步進入 Product Conformity Closure、Remaining Gap Closure、Conformity Assessment、EU DoC、CE Readiness，以及 Internal Audit / Mock Assessment 等最後整合。
所以對我來說：
2027/12/11 不應該是整套機制第一次跑起來的日期。
比較理想的是，在那之前各個主要 Process 已經實際跑過、修過，也累積了一些 Product Evidence。

十六、Roadmap 還有一個很容易放大工作量的問題：Legacy Product
企業當然不只有 New Product。
可能還有已經上市很多年的 Legacy Product。
這時真正要問的可能是：哪些 Product 到 2027/12/11 之後仍會繼續進入 EU Market？哪些已經準備 EOL？哪些還會持續 Production？哪些 Product Family 未來仍有大量 EU Design-in？
這也是為什麼我覺得 Product Inventory 不應該只有 Technical Information。
我還會想放進一些 Business Information，例如：
EU Market Status、Future EU Plan、EOL Date、Product Lifecycle、New Design-in。
因為 Product A 如果很快 EOL，Product B 未來十年仍是 EU 主力產品，Product C 根本沒有 EU Market，三者的 CRA Implementation Priority 本來就可能不同。
所以：
CRA Roadmap 最後還是要跟 Product Portfolio Strategy 接起來。

十七、我還會刻意預留時間給「第一次做得不夠好」
這是我自己做專案越久越有感的一件事情。
第一次做 Threat Model，Template 可能不好用；第一次產 SBOM，可能發現漏掉很多 Component；第一次 Article 14 Tabletop Exercise，可能才發現沒有人知道最後誰決定 Reporting；第一次整理 Technical Documentation，也可能發現 Evidence 與 Product Version 根本對不起來。
所以如果 Roadmap 排成：
每個 Deliverable 做一次就完成。
我自己會覺得有點危險。
我反而會刻意安排：
Pilot → Review → Improve → Rollout
因為 CRA 真正要建立的是一套 Capability，而 Capability 通常不會在第一版 Procedure 核准那一天就成熟。

Day 21 小結｜Roadmap 最重要的不是把甘特圖排滿，而是知道什麼不能等
做到這裡，我自己對 CRA Implementation 最大的心得是：
不要只看到 2027/12/11，就覺得所有事情都還可以慢慢來。
Article 14 Reporting 的適用時間更早；SSDLC、SBOM、Supplier Security、Technical Documentation 與 Conformity Assessment，又都需要時間建立、Pilot、調整與真正落到 Product。
所以如果讓我自己倒推 CRA Roadmap，我不會先問：
「2027 年要交哪些文件？」
我比較會先問三件事情：
哪一項義務最早開始？
哪一項能力的 Lead Time 最長？
哪些工作如果現在不開始，到了 2027 年會來不及？
這也是我自己比較習慣的：
Risk-based + Deadline-driven Implementation Planning。
而做到 Day 21，我也越來越覺得 CRA 不太像一個「做到 2027 年底就結案」的 Compliance Project。
它比較像是利用這段 Transition Period，把 Product Security Capability 一點一點放進企業原本的 Product Lifecycle。
如果有一天大家已經不再一直說：
「這是 CRA 要求，所以我們才做。」
而是開發 Product 本來就會做 Security Risk Assessment、Release 本來就會產 SBOM、發現 Vulnerability 本來就會進 PSIRT、Product Change 本來就會評估 Security Impact、Supplier Component 本來就會考慮 Security Lifecycle，我自己會覺得：
這可能才是比較成熟的 CRA Readiness。
以上仍然只是我目前研究及參與 CRA 導入後的個人心得、解讀與看法，希望拿出來和大家交流。
實際 Implementation Roadmap，還是應依公司的 Product Portfolio、EU Market Strategy、既有 Product Security Capability、Conformity Assessment Route，以及後續 Standards / Guidance 的發展持續調整。

Day 22 預告｜Roadmap 排完了，但我們到底「Ready 幾成」？
Day 21 把 2026～2027 的工作排開之後，接下來很可能會遇到一個 Management 很自然會問的問題：
「所以我們現在 CRA 到底完成幾成？」
但這題其實比想像中難回答。
Product Inventory 做完了，但 Risk Assessment 還沒開始，要算幾成？
PSIRT 有 SOP，但從來沒有實際演練過，算 Ready 嗎？
SBOM 已經可以產出，但沒有拿去做 Vulnerability Monitoring，又算完成了嗎？
Technical Documentation Template 建好了，但 Product Evidence 還沒有進來，能不能打綠燈？
我自己後來開始覺得：
CRA Readiness 不能只看「文件完成率」。
真正應該看的，可能還包括 Process 有沒有建立、Product 有沒有套用、Evidence 有沒有留下，以及真的發生事情時，整套機制到底跑不跑得起來。
Day 22，我們就來聊我自己會怎麼設計 CRA Readiness Assessment，以及怎麼避免最後得到一張「全部都是綠燈，但實際上還沒有真的 Ready」的 Checklist。